With the development of informatization, problems of malicious software such as viruses and worms are growing. Currently, more than 35,000 forms of malicious software have been found, and more than 40,000,000 computers are infected each year. To prevent these attacks, it is required not only secured transmission and inspection of data while they are being inputted, but also protection starting from the source, i.e., every endpoint connected to the network. However, conventional security protection techniques can no longer protect against the various malicious attacks.
To this end, the Trusted Computing Group (TCG) have introduced a network access specification based on Trusted Computing (TC) technology, i.e., Trusted Network Connect (TNC), referred to as TCG-TNC, which includes an open architecture for endpoint integrity and a set of standards that ensure secured interoperability. The set of standards can protect a network as needed by the user, to a user-defined level. Basically, the TCG-TNC is to establish a connection starting from endpoint integrity. Firstly, a set of policies for the operation of systems within a trusted network are established. Only the endpoints complying with the network-specified policy will be allowed to access the network, and those devices that do not comply with the policies will be isolated and located by the network. Due to the use of a Trusted Platform Module (TPM), attacks from rootkits can also be blocked. A rootkit is an attack script, a modified system program, or a set of attack scripts or tools, for illegally obtaining the highest privileges in a targeted system. The architecture of TCG-TNC is shown in FIG. 1.
In FIG. 1, Vendor-Specific IMC-IMV Messages Interface (IF-M) is an interface between an Integrity Measurement Collector (IMC) and an Integrity Measurement Verifier (IMV); TNC Client-TNC Server Interface (IF-TNCCS) is an interface between a TNC client and a TNC server; Network Authorization Transport Protocol Interface (IF-T) is an interface between a network access requestor and a network access authorizer; Policy Enforcement Point Interface (IF-PEP) is an interface between a policy enforcement point and a network access authorizer; Integrity Measurement Collector Interface (IF-IMC) is an interface between an integrity measurement collector and a TNC client; and Integrity Measurement Verifier Interface (IF-IMV) is an interface between an integrity measurement verifier and a TNC server.
However, in the TCG-TNC architecture shown in FIG. 1, the access requestor does not evaluate the integrity of the policy enforcement point, hence the policy enforcement point can not be relied upon. To solve this problem, a TNC architecture based on Tri-element Peer Authentication (TePA) has been proposed. The TePA-based TNC architecture is shown in FIG. 2.
In FIG. 2, Integrity Measurement Interface (IF-IM) is an interface between an integrity measurement collector and an integrity measurement verifier; TNC Client-TNC Access Point Interface (IF-TNCCAP) is an interface between a TNC client and a TNC access point; Evaluation Policy Service Interface (IF-EPS) is an interface between a TNC access point and an evaluation policy server; Trusted Network Transport Interface (IF-TNT) is an interface between a network access requestor and a network access controller; Authentication Policy Service Interface (IF-APS) is an interface between a network access controller and authentication policy server; Integrity Measurement Collector Interface (IF-IMC) is an interface between an integrity measurement collector and a TNC client, and between an integrity measurement collector and a TNC access point; and Integrity Measurement Verifier Interface (IF-IMV) is an interface between an integrity measurement verifier and an evaluation policy server.
To implement the TCG-TNC architecture shown in FIG. 1, the TCG has defined an implementing method for each of the interfaces in the TCG-TNC architecture, including: Remote Authentication Dial In User Service (RADIUS) defined in IF-PEP specification; tunneled Extensible Authentication Protocol (EAP) encapsulation and transport method defined in IF-T specification; message transport protocol and connection management for platform authentication (including platform credential authentication and integrity check handshake) defined in IF-TNCCS specification, which include how to route a message between an IMC and an IMV; encapsulation method for messages between an IMC and an IMV defined in IF-M specification, which includes defining an IF-M message describing attributes of the components and relating to processing attributes, such as product information attributes and security processing attributes; functions defined between a TNC client and an IMC in IF-IMC specification, to support platform authentication; and functions defined between a TNC client and an IMV, which is also to support platform authentication. Furthermore, during the process of TNC, some components in the TCG-TNC architecture may communicate with Trusted Platform Service (PTS) via a Trusted Platform Service Interface (IF-PTS). The PTS is responsible for managing an integrity measurement log, creating a snapshot and an integrity report, and providing services for some components in the TCG-TNC architecture via the IF-PTS. The IF-PTS is an interface that is not associated with the type of the architecture, i.e., the IF-PTS can be used in both the TNC architecture shown in FIG. 1 and the TNC architecture shown in FIG. 2.
Similarly, to implement the TePA-based TNC architecture shown in FIG. 2, an implementing method needs to be defined for each of the interfaces in the TePA-based TNC architecture. However, due to the significant differences between the TePA-based TNC architecture shown in FIG. 2 and the TCG-TNC architecture shown in FIG. 1, the implementing methods for the interfaces in the TePA-based TNC architecture shown in FIG. 2 should be different.